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Abstract: Business Integration has become a key issue for 
many companies to extend business market by integrating 
and streamlining processes both internally and with 
partners. To address this issue, whole marketplace has 
emerged for software solution that can help to achieve 
impr oved business integration which is referred as EAI. 
Originally EAI was only focused around integrating ERP 
with other applications within enterprise but now it is 
generally used as a catclrall term to cover all the other 
aspects of business integration. Major EAI approaches and 
evolution of enabling technologies ranging from EDI to 
Web Services and XML based process integration are 
analyzed to provide flexible, scalable and adaptable EAI 
framework. Solution comprises the challenge of efficiently 
integrating diverse business processes and data across the 
enterprises, allowing the organizations to keep pace with 
and respond to market changes. 
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1. INTRODUCTION 


Due to the explosive growth of Internet, complex business 
expansion, competitive pressures, new business models, 
and the need to streamline business processes both 
internally and with partners or suppliers/value chain has 
made Business Integration key issue for many companies. 


Enterprises need the level of internal and community based 
integration solution to help reduce cycle times, minimize 
the cost, and risk of connecting to entire value chain [1], 
and increase response and outpace the competition. Every 
business need to constantly adapt and reconfigure their IT 
assets, systems, and business operations to meet changing 
customer demands; compress business cycles; and 
differentiate from competition. However, most enterprises 
have invested in packaged, legacy, and custom applications 
that perform specific business functions which operate 
within an extremely complex, inflexible, and mostly ad hoc 
architecture consisting of monolithic silos, point-to-point 
connections and coupled hard coded interfaces. This makes 
it difficult to quickly assemble and reassemble the services . 
They provide as part of internal business processes or 
external business processes that support new and changing 
business requirements. 


The ultimate goal of business integration is therefore to 
have inter and intra-enterprise applications evolve 
independently, yet allow them to effectively and 
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conveniently use each other’s functionality. Major 
challenge in business integration is interaction, which can 
be defined as consisting of interoperation and integration 
with both internal and external enterprise applications. 
Because enterprises applications are composed of 
autonomous, heterogeneous, and distributed components 
therefore offer challenges because of issues like scalability, 
volatility, autonomy, heterogeneity, and legacy systems. 
Business integration also requires conversion of varied data 
representaions between partners’ systems and connecting 
proprietary/legacy data sources, ERP, applications, 
processes, and workflows to the Web, and trading partners’ 
systems. 


Physiology of EAI is explained through continuum of EAI 
enabling technologies [2, 3], which has been used to solve 
business integration problem and classified as EDI based, 
component based message oriented middleware, workflows, 
XML framework, and Web Services. The study demands 
state of the art complementary EAI framework based on 
business process management harnessing the Event Driven 
& Service Oriented Architecture (EDA & SOA) [4]. 


Entire study of EAlapproaches provide basis for proposed 
EAI collaborative solution framework that provides 
inter-enterprise and intra-enterprise wide process and data 
integration to enable real time business. It is recommended 
that real-time framework offer following Architectural 
features: (scalability, security, heterogeneity, adaptability, 
manageability, distributivity, decoupling, autonomy), 
real-time requirements: (asynchronous, publish/subscribe), 
and Business requirements: (flexibility, agility, usability, 
reliability) for productivity. 


The purpose of this paper is twofold; first, highlight the 
major approaches and trends in enabling technologies of 
EAI and, second, propose appropriate EAI solution 
framework guided by research dimensions. The structure of 
this paper is as follows: Section 2 discusses the basic 
concept of Enterprises Application Integration with 
classified series of enabling technologies and important 
issues. At the end of this section, major EAI platforms are 
presented with names of different EAI research projects. 
Section 3 identifies the basis of scalable EAI solution 
framework by analyzing the characteristics of various EAI 
approaches and technologies. The proposed architecture is 
presented by detailing its layers, necessary supported 
requirements, technologies and deployment model. Finally 
the EAI Collaborative Solution Framework (CSF) services 
are enlisted, followed bythe conclusion in Section 4 


2. EAI & ENABLING TECHNOLOGIES : 


2.1 Enterprises Application Integration: 


EAI entails integrating applications and enterprise data 
sources so that they can easily share business processes and 
data. Integrating the applications and data sources must be 
accomplished without requiring significant changes to 
these existing applications and data. 


Those enterprise applications that were not designed to 
interoperate, need to be integrated, enterprise and 
community wide [4]. As enterprise departments interact on 
a real-time basis and business processes cut across multiple 
enterprises and business lines, the need for information 
integration leads to the adoption of best suited EAI 
approach[6]. Thus, legacy and newer systems can integrate 
to provide the business with greater competitive advantage. 
The volatile nature of business requirements, the effort to 
lower total cost of ownership, and the need to rapidly 
introduce new products in value chains require decoupled, 
event and service oriented (SOA & EDA) functionality of 
enterprise applications. These enterprise services not only 
provide new functionality but also leverage investments in 
legacy systems running the enterprise’s key 
business -critical applications. 


2.2 EAI Enabling Technologies: 

Different technologies have bem used for business 
integration. Some of the major technologies are classified 
as: 


2.2.1 Electronic Data Interchange Based Integration: 


EDI provides __inter-organizational —_application -to- 
application transfer of business documents in a compact 
and standard form (ANSI X127], UN/EDIFACT[8]) using 
VANSs to minimize cost, effort, and time incurred by the 
paper-based transfer of business documents. EDI 
interaction using mapper, translator is shown in Figure 1. 
EDI standards define single homogeneous solution for 
content interoperability and hardly flexible in its ability to 
expand the defined set of supported document types [9]. 
Proprietary and expensive VANs are used to provide much 
secure message delivery and routing with value aided 


services (A utomatic error management eto) among partners. 


Organizations, predominantly small and medium, couldn’t 
afford EDI because of expensive VANs_ overheads 
therefore efforts to reduce the cost of using VANs include 
Internet-based EDI solutions : EDIINT [10] andOBI [11]. 
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Figurel. Interactions in EDI 
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EDI over Internet (EDIINT) uses the Internet as a 
communication medium instead of VANsto reduce EDI 
communication cost due to the use of VANs. First EDIINT 
standard AS1 (Applicability Statement 1) set the rules to 
exchange EDI documents using SMTP protocol. The 
second standard EDIINT AS2_ which supported 
communication of EDI documents using the HTTP 
protocol. Initially, there was reluctance to use the Internet 
for exchanging critical business information due to 
concerns about security. To deal with this problem, 
EDIINT AS2 specifies standard mechanisms for securing 
documents using PGP encryption and digital signatures. 


Open Buying on the Internet OB) defines Internet 
based procurement framework and _ intended for 
high-volume, low- dollar amount transactions over Internet. 
It uses HTTP protocol for exchanging messages and relies 
on ANSI X12 EDI standard to describe the content of order 
documents which are encapsulated in OBI objects with 
buyers’ and sellers’ digital signatures and provide a robust 
security infrastructure by using SSL[12] over HTTP and 
also uses digital signatures and digital certificates for 
ensuring message authenticity and integrity. Thus OBI 
ranks higher than EDI. 


2.2.2 Component Middleware Based Integration: 
Component middleware is a framework that provides 
interconnection of geographically distributed components 
by supporting the creation, deployment, and interaction 
among components [13]. Development of integration 
components in component-based application makes 
integration effective. Components are defined as modules 
that can be independently developed either fromscratch or 
by wrapping existing functionalities and then delivered 
[14]. 


Component -based integration approach caters for tightly 
coupled and long term business relationships having small 
number of partners within an enterprise. However the uses 
of message driven interaction among components allow the 
support of loosely coupled relationship. Components are 
not adoptable because businesses are tightly bound to 
interfaces published by their trading partners, and develop 
ad-hoc solutions for defining intra and inter-enterprise 
business processes by assembling applications from 
independently developed legacy components. They exhibit 
limited capabilities dealing with presentation layer. 


Major component based middleware frameworks are: 
CORBA, DCOM, and EJB. 


2.2.3 Business Process/Workflow Based Integration: 

Business process consists of collection of business related 
activities formed by data and control flow relationships (see 
Figure 2). Business process management/workflow 
management deals with declarative definition, enactment, 
administration, and monitoring of business processes. 
Workflow technology is most important for automating 
business processes which involve access to several 
applications which makes it much suitable candidate for 


integrating, automating, and monitoring business processes 


in an easy way [15, 16]. 
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Figure 2. Workflow System 


Efforts from BPMI.org deliver Inter-Enterprise Workflow 
Systems-IEWSs that have the ability to integrate 
inter-organization business processes [17] where as recent 
projects: eFlow [18] and WISE[19] focus on loosely 


coupled process with greater adaptability and 
manageability. 

Standardization process of commercial Workflow 
Management System (WfMS) from Workflow 
Management Coalition (WfMC) presents Workflow 


Reference Model [20] which was implemented in 
jointFlow[21] standard by OMG and lead to development 
of two standards: Simple Workflow Access Protocol 
(SWAP) [22] and Wf-XML message set 23]. Few other 
kinds of work flow systems known as _ Distributed 
Workflow Systems (DWSs) were also introduced which 
were appropriate for single ent erprise business process that 
needs to integrate multiple distributed wor kflows by using 
global workflow [24]. 


Inter-Enterprise Process Management Collaborative 
Framework: 


Inter-enterprise integration solution should have clearly 
defined public and private processes. Public processes 
exchange massages to business community by using 
message exchange protocols, where as private processes are 
internal business processes which also support public 
business activities. 


The concept of process wrappers can be used in private 
processes with defined activities to enable interaction 
between private and public processes. Process wrapper can 
perform document format conversion required between 
public and private processes. However when private 
processes require interaction to legacy applications in local 
business process management software then the concept of 
application adaptors [25] can be adopted for process 
compatibility. 


Introducing separate public, private business processes 
with process wrappers and application adopters in business 
process management contributes to _ scalability, 


heterogeneity and autonomy of this loosely-coupled 
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collaborative approach. Because local changes has no effect 
on public processes and business applications, changes 
related to interaction only effect process wrappers, and 
modifications in partner’s communication will just effect 
public processes. However new back-end application 
support will add application adaptor, and new partner 
relation may require few adjustments.Therefore addition of 
partners, back-end applications or interaction protocols 
does not affect private business processes. 


2.2.4 XML Based Interaction Framework: 


Basic idea behind XML based approach is to allow the use 
of services on the Web without mediation facilities and 
dedicated transformation or specific integration of partner’ s 
system. Business community will be interconnected in 

terms of largely agreed upon documents and, those XML 
documents having common set of XML schema eliminates 
dedicated translation of information. However effective 

XML _ibased_—s integration requires standardized 
domairrelated ontologies (e.g: DTDs, Schemas), mapping 
between different ontologies, means for processing XML 

documents, and service invocation. Therefore the issue of 
interoperability has now shifted from the level of 
applications to the level of standards. This can easily be 

achieved through protocol and integration engines which 
will exchange messages according to variousstandards [26]. 
Unfortunately, idea of exchanging data through XML 
documents will increase overhead. General XML based 

integration framework is shown in Figure 3. 


2.2.4.1 Microsoft BizTalk Server: 


BizTalk provides orchestration based Business Process 
Management (BPM) by harnessing SOA paradigm, through 
several technologies and standards such as XML, SOAP 
and S/MIME etc [27]. Its orchestration provides means to 
define and execute inter-enterprise process. BizTalk § 
based on centralized schema repository and layered 
architecture where centralized repository provides schema 
validation and control but also affects scalability. It refers 
to XML-based schemas for business documents structure 
and content description Document in BizTalk comprises of 
actual business document and its handling instructions, 
which are described using BizTags (standardized set of 
XML elements and attributes). More specifically BizTalk 
Document is a kind of SOAP message and _ business 
document is more like structured XML document 
containing business contents. The superset of these 
documents serves as basis of communication between BFC 
servers are BizTalk message which contains BizTalk 
document, attachments (other BizTalk, XML documents) 
and transport specific headers. 


Framework comprises of three layers: Application, BizTalk 
Framework Compliant Server (BFC), and Transport. 
Business applications interact to each other by sending 
business documents via BFC server and BFC servers use 
BizTalk messages for communication via communication 
protocols (like: HTTP and SMTP). Special BizTags make 
sure reliable delivery and offer manageability; security is 
provided via centralized security (SSO) and many secured 
protocols (SSL, PKI, S/MIME, RSA, X.509 etc.) 


Business | ehxML, RosettaNet, ete 
Process 
Layer 


Content | eC, BizTalk, cXML 
Layer ResettaNet, ebXML, etc 


Partner A 


XML, DTDs, XML Schemas, etc 


Figure3. XML Based EAI Framework 


2.2.4.2 eCO: 


eCO enables business to know and access services rather 
than standards and protocols each partner adopts[28]. eCO 
developed XML Common Business Library (xCBL) to 
define common set of XML core documents (xCBL DTDs) 
used in business transactions. user may use and extend 
documents regarding business needs. Predefined 
documents affect interoperability because businesses are 
not limited. 


Business Interface Definitions (BIDs) are used for business 
interaction at business process level to advertise business 
services. BIDs are simply XML descriptions that specify 
business services in terms of business documents. xCBL is 
used to define both interfaces of processes and contents of 
data elements, and restrict appropriate tag selection by the 
partners. 


To address semantic heterogeneity, domain specific 
ontologies (schemas) can be defined with necessary 
mappings. Separation of services description and 
implementation contribute to autonomy and new business 
services just require service description (interfaces, types 
etc.) and integration of service int erfaces with internal 
application. As partner’s systems are loosely coupled 
therefore local changes are limited. 


Few other XML based integration frameworks are: 
Commerce XML (cXML) [29], RosettaNet [30], Electronic 
Business XML (ebXML) [31]. 


2.2.5 Web Services Based Integration Framework: 
Service Oriented Architecture (SOA) Paradigm: 


An architectural paradigm for creating and managing 
“business services” that can access distributed business 
functions, IT assets, and information with a common 
interface regardless of the location or technical makeup of 
the function or data. This interface must be agreed upon 
within the environment of systems that are expected to 
access or invoke that service. It supports new business 
requirements through the creative use and reuse of existing 


assets in quick and easy way . SOA offers: Loosely Coupled, 


Request/Reply, and Synchronous Communication support. 


Web Services (WS s): 


Web Service is an implementation and important aspect of 
SOA [32]. WSs are loosely coupled applications using open, 
cross-platform standard which interoperate across 
organizational and trust boundaries; they are free from 
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Partner B 


_ 


client context and deployment requirements [33, 34]. 


Specifically Web Services are platform independent, 
loosely coupled, dynamically located and invoked, firewall 
friendly and widely accessible which makes them 
appropriate for economical EAIsolution[35, 36, 37]. They 
use open XML and Internet-based protocols for their 
description, registration and invocation: Web Services 
Description Language (WSDL) used for describing 
operational features [38]; Universal Description, Discovery 
and Integration Language (UDDI) provides programmatic 
interface for publishing and discovery [39]. Simple Object 
Access Protocol (SOAP) [40] offers lightweight messaging 
framework for exchanging XML formatted data, supported 
by variety of transport protocols (HTTP, FTP, SMTP), and 
structured as envelop containing header (features like 
security, transaction etc) and body (actual data). Other 
standards like: WS-Security, Monitoring and Management 
(WS-DM) are developed, in addition to: WS-Reliable 
Messaging, WS-Eventing and WS-Notification which are 
in standardization process. Interaction among WSs is 
shown in Figure 4. 


Adoption of an XML based messaging (SOAP), and use of 
document based messing model, over well-established 
protocols enables communication among heterogeneous 
systems and loosely coupled relationship. Standards like 
BPEL4WS [41] could be used for business process 
definition through WSs. Heterogeneow applications 
(CORBA, Java etc.) may be wrapped and exposed as WSs. 
However WSDL neither model semantic features 
(document type: PO etc) nor include security oriented 
information, such as role based access control etc. 
regarding adoptability service signature may change, which 
require automatic detection and handling of changes. Using 
tagged language for data exchange and use of complex data 
types, which are not supported in SOAP and require XML 
parser to load XML schema from remote location, will 
overload the network. Another scalability issue refers to 
registry which could be centralized, distributed and 
replicated. 


» De Publish (UDDI Publication) 
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Service Description (WSDL) 
Figure 4: Web Services Reference Model 


WS Composition standards for BPM: 


Many efforts have been made for developing standards for 
WS composition [42], such as XLANG [43], Web Services 


Flow Languages (WSFL) [44], Web — Services 
Choreography Interface (WSCI), Business Process 
8 


Modeling Language (BPML) and finally superseding, 
Business Process Execution for Web _ Services 
(BPEL4WS). 


BPEL4WS: Widely acceptable standard which provides 
service composition using orchestration support and 
combines XLANG (provide structural construct for 
processes) and WSFL (enable graph oriented process). 
Business process is defined through many activities (eg: 
invoke WS), which are combined into Structure Activities; 
such as: Sequence (order of activities), Switch (branching), 
While (loops), Pick (path selection), and Flow (parallel 
execution). It also supports error handling (catch, throw) 
and compensation (compensation actions) within the scope. 


2.3 EAI Platforms & Research Projects: 


Following are the platforms to develop EAI solutions: 
TIBCO Active Enterprise, Mercator Enterprise Broker 5.0, 
Oracle Integration Server, HP Net Action IOE, IBM 
Websphere Business Intigration Suit, Miscrosoft BizTalk 
Server 2004, Microsoft .NET, Sun Open Net Environment, 
Vitria Business Ware, Versata Global 2000, BEA 
WebLogic Integrator, Web Methods, and SeeBeyond 
E*G ate Integrator, etc. 


In addition few research projects are also deveveloped 
using different approaches, like: HeavenStar Flow, eFlow, 
WebBIS, SELF-SERV, XL WISE, CMI, CrossFlow, and 
Mentor - Lite etc. 


3. EAI COLLABORATIVE SOLUTION 
FRAMEWORK ARCHITECTURE: 


Aim of this paper was to present physiology of EAI with the 
intent to introduce appropriate EAI solution, therefore the 
bases of framework are proposed as follow: 


3.1 Architecture Service Layers: 
Scalable EAI framework comprised of three service layers: 


Transport Service Layer: Pure loosely coupled 
architecture is claimed through document based 
communication model; therefore business applications 
communicate through diverse business documents via 
various protocols. Transport service layer provides 
appropriate protocols to exchange documents between 
business communities . In general partners can use different 
protocols for documents which require gateway service/ 
transport service to translate documents between 
heterogeneous protocols. 


Presentation Service Layer: After receiving the business 
document from transport service layer it must be identified 
and understood in such a way that the information provided 
in that document could be accessed by the system and other 


lower service layer . Major services of presentation layer are: 


document transformation (using mappings), information 
translation and integration among disparate representation. 
In short we can say that it mostly deals with content 
semantics regarding type of business document and 
provides integration of data models and document format. 
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Value Aided Services (VAS) Layer: The major 
requirement of business partners is to integrate diverse 
business processes for cross organizational business 
processes which is done through VAS/Business Process 
Integration layer and require well-defined agreed upon 
business process After the identification and 
transformation of business document by presentation 
service layer the information is transferred to VAS layer 
where certain business process related to document is 
applied. Objective of this layer is to provide interaction 
among business process of autonomous and heterogeneous 
partners therefore interpretability at this layer is a 
challenging issue which requires well defined agreed upon 
business processes. 


Layered service architecture (see Figure 5) supports 
peer-t o-peer communication among business partners and it 
depends upon situation that which level of service is 
required. Some times business integration may require 
transport services only, or for some situation business 
integration is required till presentation service, or it may be 
possible that business is integrated to highest level known 
as value aided service layer for process integration. 
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Figure 5: Collaborative Solution Framework Service Layers 


There must be few services across all the layers to claim 
reliability and manageability like: 


Tracking Services: 


Provide Tracking and Monitoring facilities. Every service 
informs their activities to tracking manager, which maintain 
tracking and monitoring log When any failure is reported 
to tracking manager it transfers that activity to Notification 
Manager. 


Configuration and Failover Recovery Services: 


Configuration manager continuously monitor the services; 
if any service is found fail then it is informed to Notification 
Manager. It also maintains system’s metadata. Once any 
business document fails to receive service due to document 
error or service failure it is notified to configuration 
manager by that layer which logs failure configuration in 
configuration database and when the failure is recovered it 
is kicked back through recovery service. It also offers load 
balancing. 


Notification Services: 


Provide Notification Services to monitoring staff through 
available modes of transportsuch as: e-mail, Fax, and SMS 


After reception of failure notice, the failure is recovered. 


3.2 Architectural, Real -time & Business Requirement 
for EAI Framework: 


It is recommended that real-time EAI solution framework 
offer following architectural features: (scalability, security, 
heterogeneity, adaptability, manageability, distrib utivity, 
decoupling, autonomy), real-time requirement: 
(asynchronous, publish/subscribe) and business 
requirements: (flexibility, agility, usability, reliability) for 
productivity. 


3.2.1 Scalability: A bility of a system to grow in different 
dimensions is referred as scalability. In business 
community establishment of new relationships in low cost 
and efforts are desirable. Therefore provision of business 
services component templates and establishment of new 


business processes through orchestration ensures 
framework scalability. 
3.2.2 Security: It requires mutual authentication, 


authorization, confidentiality, and non-repudiation. This is 
supported with Partner’s Authentication, SSL, SHTTP, 
S/MIME and PKIsecurities. 


3.2.3 Heterogeneity: Different levels of heterogeneity 
exist within partners like: Structural Heterogeneity, and 
Semantic Heterogeneity. In general degree of dissimilarity 
between partners is referred as heterogeneity. In document 
based communication model, it is fulfilled by providing 
document validation, translation, transformation and 
transportation in diverse forms. 


3.2.4 Adaptability : Ability of system to quickly adapt to 
dynamic business changes .Because impacts of changes are 
limited in layered architecture therefore changes are 
incorporated in specific service component for adaptability. 


3.2.5 Manageability: Degree of application’s visibility and 
manageability such as_ supervision, control and 
performance of its execution, which is provided by tracking, 
notification, configuration, and recovery services. 


3.2.6 Distributivity: A bility to separate group of common 
services into different integration levels and connect them 
appropriately to provide required level of integration. This 
is achieved by orchestration facility which integrates 
various service components at different layers and compose 
them in form of web service for certain business processes. 


3.2.7 Loose Coupling: The most important feature of EAI 
that partners should not be dependent on each other and 
exchange business information on demand. Impact of 
changes closely depends on the degree of coupling. 
Document based communication model is followed. 


3.2.8 Autonomy: Provides more local control over local 
services and allow maximum flexibility to change 
processes without effecting each other, such as each partner 
is viewed as a black box. Therefore partner’s integrations 
are not effected due to EAI Hub Model. 


With reference to EDA real time business support 
following is required: 
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3.2.9 Asynchronous: In asynchronous business demand, 
information should be sent without the expectation of an 
immediate response or no requirement of maintaining a live 
connection among two systems while waiting for response 
which offer more independence, and achieved by queued 
document facility by using message queuing facility in 
asynchronous business demands or in case of failure. 


3.2.10 Publish/Subscribe: Provides many-to-many 
consumer/producer interaction such as once producer 
produces information about an event that must be received 
by all authorized consumers. It is accomplished through 
CSF DB by making consumer/producer relationships 
accessed by every activated business process service. 


Descriptive approach to BPM increase framework usability; 
and scalable service based layer approach makes business 

implementation flexible to cover business agility, whereas 

recovery service and multiple instances framework 

deployment in parallel claims ultimate reliability. 


3.3 EAI Framework Technologies and Architecture: 


Business integration is done by making use of descriptive 
BPM to describe process workflow which involves 
selection of different service components from respective 
layers. Transport layer contains common transport wrapper 
components based on .NET COM components to support 
different forms of transports. They can be created and 
customized through common templates. Presentation layer 
is based on multiple common WSs for mapping and 
transformations. For process integration; Business 
validations are enabled using WSs at VAS layer. Common 
business logics with respect to sectors are already exposed 
in WSs form which can easily be customized. Inter layer 
communication is achieved through MSMQ (see Figure 6 
on next page). 


3.4 EAI Hub Model: 


CSF is centrally managed where every partner is required 
to send their business documents to CSF Hub where their 
business is integrated. No changes are expected in partner’s 
application except application adaptors for certain 
situations (see Figure 7 below). CSF Hub must be 
supported by Backup Exchange. 


Colebrative Solutions Frame work 


Figure 7. EAI Hub Model 
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Figure 6: Collaborative Solution Framework Architecture Summary 


4. CONCLUSIONS 


Different EAI technologies can be viewed as 
complementary, if they are properly adopted and 
structured. However basic findings are: making use of 
graphical BPM which can compose WSs _ compliant to 
SOA could be effective. Loosely coupled document based 
communication seems scalable. XML based data transfer 
using WSs should be avoided to minimize network traffic, 
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support wide variety of transports, and easily adoptable 
for partners. 
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